In this specification we will refer specifically to OPC (OLE—object linking and embedding—for Process Control) systems since these have become a de facto standard. However the skilled person will recognise that the techniques we describe are not limited to such systems.
Broadly speaking OPC systems tend to be implemented where there is a need for continuous or batch process control, for example in a chemical manufacturing plant. Typically there are many sensors and actuators/control devices, for example temperature sensors, valves, blowers and the like. These transducers are coupled into one or more networks, to which are also coupled one or more OPC servers which provide an interface to the transducers. Generally a model of the process runs as a separate application either on the same or a different node to the server. Such a model may provide overall control of the manufacturing process, for example to control and optimise efficiency which, in the large scale processes of the type described here, can be economically very important. The model may be implemented using an OPC client, although OPC clients may also be used for other purposes—for example some OPC clients are read-only reporting tools.
Historically proprietary technology was employed to provide an interface to each industrial device or transducer but more recently a distributed client-server architecture has developed which uses a set of de facto standards developed by the OPC Foundation to interface between data access servers and clients. Thus an OPC server will provide one or more sets of APIs (Application Program Interfaces), each set of APIs comprising some which must be supported and some which are optional. OPC certification that a server or client complies with these is also available. Current and emerging OPC specifications include OPC Data Access (currently at version 3); OPC Alarms and Events; OPC Batch; OPC Data eXchange; OPC Historical Data Access; OPC Security; and OPC XML-DA. There is also a plan for OPC UA (Unified Architecture), that is a single specification to encompass some or all of the above specifications. The OPC interfaces conceal the underlying complexity, for example the precise form of network communications, and OPC itself generally (apart from XLM-DA and UA) uses the Windows DCOM (Distributed Component Object Model).
We have described features of the OPC specification above because they are helpful for understanding the operation of embodiments of the invention. However the skilled person will appreciate from the later description that embodiments of the invention do not rely upon any particular form of the OPC specification. More particularly it will be seen that one of the advantages of embodiments of the invention is that they are independent of any particular OPC API set.
Commonly a manufacturing or industrial process control system operates in a complex and distributed computing environment and there are many events which can compromise access to OPC data. Computer or network hardware can fail and hardware and software may need to be upgraded—for example frequently a node may need to be rebooted following installation of a Windows™ security update. However it is also important to keep down time of the system to a minimum and, in particular, to provide for failure of an OPC server.
FIG. 1 shows an example of a proxy OPC server design architecture with a pair of OPC servers 10a, 10b coupled to an OPC client 14 by means of a proxy OPC server 16, to enable failover from one OPC server to another in the event of failure. The proxy server 16 runs on the OPC client node, and the OPC client connects to the proxy server which in turn directs the OPC data transaction to one of the two real OPC servers 10a,b. This architecture offers the possibility of a seamless, no data loss OPC transaction during failure of an OPC server but this comes at a cost: the proxy OPC server is a complex entity that has to be kept up to date and that has to fully implement all required and optional OPC interfaces; the architecture complicates and potentially compromises the complex DCOM security configuration; and the proxy server can also reduce performance of the client transaction and potentially increase the load on the underlying data source by getting both the underlying OPC servers to process the OPC transaction. Moreover although the architecture of FIG. 1 provides redundant servers it itself introduces a new single point of failure, that is the proxy server 16, and if the proxy server fails the OPC client cannot access OPC data.
Further background material can be found in US2004/0006624.
There is therefore a need for improved techniques for adding redundancy to a manufacturing or industrial process control system such as an OPC system.